1. Field of the Invention
The present invention relates to systems and methods of presenting messages to computer users, and in particular to a method of formatting and grouping such messages according to a message context.
2. Description of the Related Art
Graphical user interfaces (GUIs) provide an easy to use, intuitive computer interface. A GUI typically includes a number of components such as input fields or areas that allow the user to enter data for computer program parameters or variables. GUI input fields or areas can also be used to accept user input defining parameter or variable names and characteristics.
In many cases, the parameters or variables (and hence, the data entered into the input fields) are subject to input data value and/or format constraints. Users must adhere to these constraints when entering data into the fields, or errors will result. For example, DOS filenames cannot exceed eight characters, optionally followed by a period and an extension that cannot exceed three characters, and cannot include characters such as backslashes. Database object names, such as names for tables and stored procedure parameter names have similar restrictions.
Multiple related input fields, each for different parameters or variables, may be grouped together and presented to the user in a dialog box or window. After data has been entered into the required input fields, the user may select an “OK” button, and the data in each field is accepted and stored accordingly.
A GUI can respond in many ways when the user violates an input field constraint. One way to respond is to wait until the user tries to commit all changes, then beep and present a dialog box informing the user of the error and information to educate the user as to the proper input form. One drawback of this technique is that it is often difficult for the user to associate the information in the dialog box with the constraint violation. For example, if the user entered data into multiple fields, the user will not know which input field is incorrect. The user must click OK on the error message dialog, associate the error message with the input field in error, select the text in the field in error, and then make the correction. This behavior maximizes the effort needed to commit a change that doesn't violate any constraint.
Another way the GUI can respond to an erroneous input is to fix the errors without asking for user intervention. For example, if a comment field cannot contain a specific set of impermissible characters, those characters could be automatically stripped out before the comment is committed. This technique has disadvantages as well. First, the user may want the impermissible characters, not realize they have disappeared, and write new code that depends on their entry. This technique also does nothing to educate the user, and even worse, misleads the user into thinking no constraint has been violated.
Another way the GUI can attempt to solve the foregoing problems by avoiding the use of input fields altogether. For example, a length parameter can be specified with a slider bar or a combo box with all possible values in it. This technique is feasible for some parameters (e.g. specifying decimal precision, which generally ranges only between 0 and 31), and infeasible for others (i.e. specifying a BLOB length, which ranges from 1 to 2 gigabytes). Such controls avoid problems with lower and upper limits, and can also reflect context changes. However, such controls are not as flexible as editable text fields. For example, only an editable text field is suitable in cases where the same control (for consistency reasons) must serve as the length of (alternatively) a BLOB and a DECIMAL precision. Further, the name of a new object cannot ordinarily be specified with any other type of control other than an editable text field.
In some circumstances, it is advantageous for the user to defer presentation of diagnostics until all of the input data has been entered. This may be the case, for example, when the user is creating a “batch” process such as code generation or project validation, which often result in multiple constraint violations. Application development tools typically have a message window that contains a GUI list component to display a sequence of messages. To be useful, the message often must be longer than the width of the list box. However, all such list boxes in current use continue each message to the right, beyond the viewable area, and every item in the list box is constrained to be the same height. Further, messages are not grouped according to the statements or objects in error. Instead, each message is preceded with its own context description, which may include a class name, method name, file name, and line number. This requires the user to use a horizontal scroll bar to read the end of the message. When the view is scrolled to the right, the context descriptions and beginning of the messages are not visible, which means that the user loses the contexts of the messages and cannot tell from reading the right end of the next message whether it is for the same or a different context. When the view is scrolled to the left, the end of the messages are not visible. Hence, the user is saddled with the frustrating task of scrolling back and forth to read a series of messages.
As is apparent from the foregoing, there is a need for a computer interface that presents a list box organizing messages by context, and presenting the entire message without the need for horizontal scroll bars. The present invention satisfies that need.